Since much GeoServer work actually takes place in GeoTools we thought offering some advice on how to work in GeoTools might be in order. First completely read the Developers Guide, as we do not want to replicate information there, we just want to give some GeoServer specific tips that are not found there.

Updating GeoServer with GeoTools jars.

The first is building, and moving jars to GeoServer. Any module or plugin can be individually built using the maven jar:install command. This is useful especially for the plug-ins, as a new DataStore can easily be modified, built, and plugged right in to GeoServer. To move from GeoTools to GeoServer the jar will be located in target/. Generally the names of the jars in GeoServer are a bit different from what GeoTools calls them, be sure to rename to the GeoServer name so that they do not conflict. Putting the jars in the geoserver/lib directory of the source tree will insure that any subsequent build will pick up the jars. But that can be a bit cumbersome, rebuilding the war every single time, so one way we have found around that is to copy the jars directly to a running GeoServer instance, under webapps/geoserver/WEB-INF/lib. Then merely restarting the servlet container will pick up the changes. This can even be done for the main module of gt2.

Where to put new Code?

The second is where new code should live. GeoTools work begs extensive review from the whole team of developers, which many new GeoServer developers have found a bit frustrating. Others simply aren't initially comfortable with the size of the GeoTools code base and have not studied it enough to know where their improvements should go. For this reason GeoServer often allows major work to take place in GeoServer first, and later rolled in to GeoTools. We've had good success with this approach, as it gets the initial requirements of GeoServer out and working, and then allows the GeoTools team to evaluate from a working implementation, refactoring as appropriate, instead of designing from scratch. The one thing we do advise though is that we will only temporarily allow work that should go in GeoTools in GeoServer. It is extremely important that we do not fork core functionality from GeoTools, that instead we continue to roll it in, or else GeoServer will be stuck with it's own feature model, which is exactly what we wanted to avoid in joining with GeoTools. So if you do work GeoServer on code that should be in GeoTools, your functionality will not be rolled in to an official release until it is properly in GeoTools. This practice ensures that the changes are done right, reviewed by a number of people, instead of just focused on very narrow needs.

New DataStores

Also note that work for DataStores is done entirely in GeoTools. If you are simply interested in adding a new data format to GeoServer then your work will take place entirely in GeoTools. Read the DataStore Tutorial in GeoTools for information on how to write a new one. GeoServer will be more than happy to test out new DataStores, we have started allowing additional downloads of more experimental versions for users to try out. Once it is all tested we roll it in to the main GeoServer distribution. Doing this work in GeoTools ensures that other GeoTools based projects, such as uDig, can make use of the work as well.